home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / dhc / dhc-minutes-92mar.txt < prev    next >
Text File  |  1993-02-17  |  9KB  |  189 lines
  1. This is only a rough draft - Megan 04/15/92
  2.  
  3. Here are the minutes from the DHC WG meeting in San Diego:
  4.  
  5. The DHC WG held two meetings in San Diego, on Tuesday afternoon and Thursday
  6. morning.  In addition, Ralph Droms gave a technical presentation to the IETF
  7. summarizing DHCP. In the Tuesday meeting, the WG discussed changes to  DHCP,
  8. as reflected in a new version of the DHCP Internet Draft, dated March, 1992:
  9.  
  10.  
  11.  
  12.   o Modified  introductory  text to  state that  DHCP  allows but  does  not
  13.     require the configuration of higher level protocols.   Vendor extensions
  14.     for NIS have been defined.  Others will be allowed.
  15.  
  16.   o Extended the  definitions of the 'htype', 'hlen' and 'chaddr' fields  to
  17.     accommodate client identifiers that might not be hardware addresses.
  18.  
  19.   o Replaced 'byte' with 'octet' throughout.
  20.  
  21.   o Added text  allowing servers to use  the same local broadcast  mechanism
  22.     as BOOTP relay agents when sending DHCP messages to clients.
  23.  
  24.   o Added a  new mechanism for clients  that do not request dynamic  address
  25.     allocation.
  26.  
  27.   o Added a  new 'message' vendor extension, which  may be used by a  server
  28.     to  pass an ASCII text message  to a client,  e.g., an error message  if
  29.     the server cannot satisfy a client request.
  30.  
  31.  
  32. Several minor changes were  discussed, which will be  integrated into a  new
  33. version of the DHCP I-D:
  34.  
  35.  
  36.   o The I-D  will give details of  mechanisms through which hosts can  check
  37.     to  determine  if its  network  address is  already  in use  by  another
  38.     host.    For example,  a host using  ARP can  issue an  ARP request  for
  39.     its  network  address to  see  if another  host  answers.    As  neither
  40.     RFC  826  nor RFC  1122 address  this  use of  ARP,  the DHCP  I-D  must
  41.     explicitly  describe how a  host can issue  an ARP request  for its  own
  42.     address;  specifically, the host must use  some other IP address  (e.g.,
  43.     0.0.0.0) as the 'sender's protocol address' in the ARP  request to avoid
  44.     corrupting other hosts' ARP caches.
  45.  
  46.   o Hosts  must delay  some short,  random time  at  boot-up before  issuing
  47.     an  initial DHCP message,  to avoid swamping  the network with  multiple
  48.     simultaneous  DHCP messages  in the  case of  synchronized host  boot-up
  49.     (e.g., power fail/recover cycle).
  50.  
  51.   o Figure 2 will  be modified to include a second server and to delete  the
  52.     final DHCPRELEASE message.
  53.  
  54.   o Section 6.2.1 will be rewritten to reflect the use of  the new REBOOTING
  55.     state  and DHCPREQUEST message  by hosts that  retain a network  address
  56.     across system reboots.
  57.  
  58.                                      1
  59.  
  60.  
  61.  
  62.  
  63.   o The 'message' vendor  extension will specify the use of NVT ASCII  text.
  64.     Use of MIME multi-media message format was considered and rejected.
  65.  
  66.   o The definitions of the vendor extensions (Appendix D in  the March, 1992
  67.     Internet Draft)  will be extracted and submitted as a separate  Internet
  68.     Draft.   Definition of new vendor extensions in the future will  require
  69.     only  the resubmission of  the vendor extension  Internet Draft,  rather
  70.     than the entire DHCP Internet Draft.
  71.  
  72.   o The  DHCP specification Internet  Draft will be  rewritten with  careful
  73.     use  of MUST/MUST NOT/SHOULD/SHOULD NOT/MAY  to reduce ambiguity in  the
  74.     specification.   Special attention will be paid to the specification  of
  75.     the  fields to be used  and the valid vendor  extensions in each of  the
  76.     DHCP messages.
  77.  
  78.  
  79.  
  80. There were  also several  topics that  sparked longer  discussions.    These
  81. topics, in general, remain unresolved:
  82.  
  83.  
  84.   o The relationship between BOOTP and DHCP should be  clarified by renaming
  85.     DHCP as BOOTP.
  86.  
  87.   o Various  levels of compliance with  the DHCP/BOOTP specification  should
  88.     be indicated by  ``BOOTP Level 0,'' ``BOOTP Level 1'' and ``BOOTP  Level
  89.     2.''
  90.     DISCUSSION: There  is the potential for  confusion on the part of  naive
  91.     users  about the  relationship between  BOOTP and  DHCP.   For  example,
  92.     BOOTP  clients  will continue  to  work with  DHCP  servers;  will  DHCP
  93.     clients  work with  BOOTP  servers?    The relay  agents will  still  be
  94.     known as ``BOOTP  relay agents''; will those work with DHCP clients  and
  95.     servers?
  96.     Some client  implementations of DHCP may  not include all the  functions
  97.     specified in the DHCP Internet Draft.  In particular,  members of the WG
  98.     have expressed concern  that some DHCP clients may be unable to  enforce
  99.     the network address lease rules, and may always require  allocation of a
  100.     network address with an infinite lease.
  101.     The WG proposes renaming DHCP to BOOTP, and  subsuming the specification
  102.     of  the  current BOOTP  protocol  into the  DHCP/BOOTP  document.    The
  103.     various type of DHCP/BOOTP service would be names:
  104.  
  105.      --  BOOTP Level 0 -- BOOTP as defined in RFC 951.
  106.  
  107.      --  BOOTP  Level  1  --  DHCP/BOOTP  with  automatic   network  address
  108.          allocation and only infinite leases.
  109.  
  110.      --  BOOTP  Level 2  -- DHCP/BOOTP  with  fully dynamic  (finite  lease)
  111.          network allocation.
  112.  
  113.   o Does  DHCP need  to deliver more  parameters in  vendor extensions  than
  114.     will fit in a single DHCP message?
  115.  
  116.                                      2
  117.  
  118.  
  119.  
  120.  
  121. o If  DHCP  delivers  more parameters  than  will  fit in  a  single  DHCP
  122.   message, how should those additional parameters be delivered?
  123.   DISCUSSION: Some  members of the WG contend  that DHCP must, indeed,  be
  124.   prepared  to deliver  more parameters  than will  fit in  a single  DHCP
  125.   message.   One  argument in favor  of that view  is that specific  sites
  126.   will  want to  deliver  additional DHCP  parameters,  and, if  the  DHCP
  127.   document does not explicitly specify the use of  a particular mechanism,
  128.   each site may choose a local (and potentially incompatible) mechanism.
  129.   Other  members  of  the  WG  feel  that  DHCP   can  deliver  sufficient
  130.   parameters  in  a  single  message  to configure  a  host.     Based  on
  131.   the  currently defined  vendor extensions,  and assuming  ``reasonable''
  132.   lengths  for variable  length  vendor extensions,  DHCP could  send  all
  133.   parameters  specified  by  vendor  extensions  in  roughly  280  octets.
  134.   Counting  the 'sname'  and  'file' fields,  a  single DHCP  message  can
  135.   deliver 502  octets of vendor extensions.   Thus, DHCP can, at  present,
  136.   deliver all necessary parameters to a host in a single DHCP message.
  137.   The  WG discussed a  mechanism called  a ``bill of  lading'' to  provide
  138.   reliable  delivery  of  vendor extensions  in  multiple  DHCP  messages,
  139.   if  DHCP  is defined  to  support vendor  extensions  in excess  of  502
  140.   octets.   A bill of lading is  a bit vector representing all 256  vendor
  141.   extensions.  The DHCP server will deliver a bill of  lading to the host,
  142.   indicating  which vendor extensions the  host must receive  with a 1  in
  143.   the corresponding bit in the bit vector.  The  host will then repeatedly
  144.   ask  for DHCP  parameters, checking  off specific  vendor extensions  as
  145.   they arrive, until all specified vendor extensions have been delivered.
  146.  
  147. o Should a host use DHCP at every reboot to reacquire network parameters?
  148.  
  149. o If  the host cannot contact  a DHCP server at  reboot, should a host  be
  150.   allowed to reuse previously acquired network parameters?
  151.  
  152.  
  153.    1.  Required use of DHCP: A DHCP host should likely be required  to use
  154.        DHCP whenever the local network parameters may have  changed (e.g.,
  155.        system reboot, network  failure and restart), as connected  network
  156.        may change w/o  host's or user's knowledge (consider change  inside
  157.        wiring closet w/o user notification).
  158.  
  159.    2.  Application of  lease:  does  the lease apply  to just the  network
  160.        address or  does it apply to  all network parameters?   I.e.,  host
  161.        is allowed to reuse stored network address (careful here;  host may
  162.        have bogus network address and not be able to contact server).
  163.  
  164.    3.  Authority of DHCP server:   should server be able to force host  to
  165.        take new network values; i.e., "remote manage" the host?
  166.  
  167.   DISCUSSION: The  conversation about this topic began with  consideration
  168.   of whether or not to allow a DHCP host should be  allowed to continue if
  169.   it cannot contact a DHCP server at reboot.   THere were strong arguments
  170.   for and  against -- for:  allows  for partial network operation even  if
  171.   DHCP servers  are inaccessible; against:  may allow misconfigured  hosts
  172.   to  operate.  Note  that only network  parameters can be  misconfigured;
  173.  
  174.                                    3
  175.  
  176.  
  177.  
  178.  
  179. DHCP guarantees  that any network address  will be assigned to only  one
  180. DHCP host.
  181. The  WG then  discussed the  relation between  the  'lease' and  network
  182. parameters;  should the  lease apply to  all parameters or  just to  the
  183. network  address.   A  proposal was  floated for  another bit-vector  to
  184. describe  those network  parameters to  which the  lease applied.    The
  185. idea here  is to provide some  degree of network management through  the
  186. guarantee  that DHCP  hosts would periodically  reacquire new  (possibly
  187. changed) network parameters.
  188.  
  189.